The Gigabit Passive Optical Network (GPON) system is organized in the following manner. Optical network terminals (ONTs) are located closest to the end users of the network and transmit information to and from the user into a Passive Optical Network (PON) link. On the other side of the PON link is an optical line terminal (OLT), which aggregates the data from several different ONTs (typically 32 per PON link), and possibly multiple PON links, and sends the data on into the core network.
Typically, the computers/devices connected to the ONT transmit Ethernet/IP packets, meaning that the level 2 protocol is Ethernet protocol and the level 3 protocol is Internet Protocol (IP). Therefore, the ONT ultimately receives and sends Ethernet packets. The amount of data an ONT can send in a given time frame is fixed by the OLT through a process called bandwidth allocation. In order to efficiently utilize the allocated bandwidth, the ONT fragments the Ethernet packets it receives, and wraps them into G-PON Encapsulation Mode (GEM) frames. Each GEM frame can contain a full Ethernet packet, multiple Ethernet packets, partial Ethernet packets, or any combination of the above. Therefore, the GEM frames are launched into the PON link. These frames are decoded by the OLT at the other end of the PON link, and Ethernet fragments are extracted from these GEM frames and are re-assembled at the OLT.
GEM is a method for encapsulating data over a GPON. Although any type of data can be encapsulated, the data types to be encapsulated depend on the service situation. GEM provides connection-oriented communication as well as Asynchronous Transfer Mode (ATM) communication. The concept and framing format may be similar to Generic Framing Procedure (GFP).
FIG. 1 shows how this fragmentation can induce network congestion. FIG. 1 shows a PON link over which ONT1 transmits fragments of three Ethernet packets in its time slot E1, F1, and G1, where the number represents the fragment number and the letters denote different Ethernet packets. In general, this can happen if E, F, and G belong to different traffic classes (the OLT allocates bandwidth separately to different classes of traffic). When these fragments are transmitted, ONT1's transmission window runs out. Therefore, these fragments cannot be transmitted by the OLT into the network, and thus remain in the memory until the final fragments of these three Ethernet packets arrive. This happens at time T2, when ONT1 begins transmitting again and sends fragments 2 of E, F, and G, labeled E2, F2, and G2, respectively. Now, the OLT has three packets to transmit within a relatively short window, and wasted transmission time in the previous window, waiting for the fragments to arrive. Therefore, fragmentation and reassembly can induce congestion in an otherwise smooth stream of traffic.
A second issue is the hardware associated with reassembly. Clearly, the OLT needs to store the Ethernet fragments in a memory. When new fragments arrive, the OLT must find out whether the Ethernet fragments form a complete packet and, if so, pass the packet on through the network. As with any buffer based solution, we need to be concerned about buffer overflows that can result from an ONT reset/missed or lost packets. All of these cases create a substantial implementation overhead for the ONT. Thus, there is a need in the art for an improved system and method for communication in optical networks.